Application software, also known as an application or an app, is computer software designed to help the user to perform specific tasks. Examples include enterprise software, accounting software, office suites, graphics software and media players. In recent years, the abbreviation “app” has specifically come to mean application software written for mobile devices. Application software applies the power of a particular computing platform or system software to a particular purpose. In other words, applications make use of the operation system of a computing device to gain access to the hardware resources. Applications also require access to a graphics environment for interaction with the end user. These software applications (often called native applications) use a hardware execution engine such as a Central Processing Unit (CPU). An application's dependency upon existing resources in a specific computing device means that the software provider may need to provide different versions of the application for execution on different device platforms. A virtual machine execution model enables a software provider to distribute a single application for execution on multiple different device platforms. Scripting languages in combination with a graphics environment are an alternative for a virtual machine execution model, providing similar multi-platform benefits. This approach has been adopted for web applications and in the HTML-5 W3C recommendation.
Many applications require the software to be limited to a single end user computing device (or client device). This can be achieved by making the execution of the software application dependent on a hardware function that is specific to a single end user device.
So-called “node locking” (or “hardware anchoring”) technologies provide a software application with a hardware dependent function for integration into its execution path (see, for example EP2506174 and EP2506175). This provides a mechanism to lock the execution of the application to a specific end user device. The node locking function also enables an application to generate a message demonstrating that the application is operating on a particular end user device. This can be used for authentication purposes. These node locking applications describe a challenge-response function that is specific for a particular hardware circuit. A challenge-response methodology generally relies on a secret in a hardware device. Knowledge of the secret enables the generation of challenge-response pairs which enable an application to verify that the application is executing on the intended platform. EP2506174 and EP2506175, as referenced above, describe systems and methods for using a node locking function (a challenge-response function) in combination with secured software applications.
Node locking technologies for software applications require the availability of a function that is specific to a particular end user device. EP2506175 achieves this by leveraging a specific function of a standard Subscriber Identity Module (SIM), e.g. in a mobile telephone. As the Operating System generally does not expose the SIM functionality to applications executing on the device, the SIM locking mechanism of EP2506175 requires modifications to the Operating System of the device. Thus, this challenge-response solution is undesirable in some circumstances. EP2506174 requires specific hardware features in a device, which makes this challenge-response solution unsuitable for use with an existing device infrastructure.
Even if node locking techniques are available to local applications, web based applications (e.g. based on HTML5) that operate in a browser, do not have access to such node locking facilities since the browser Application Programming Interface (API) does not expose such functions/facilities to the web applications.
Digital Rights Management (DRM) technologies are well known for controlling access to protected content files. A protected content file comprises an encrypted content part and a usage rules part. The client DRM system first processes the usage rules to generate a content decryption key that is used to decrypt the content part. Note that the usage rules part typically includes encrypted elements. The DRM implementation in the end user device is implemented in a tamper resistant way, in order to defend against attacks against the implementation.
DRM Systems are generally used by movie and music rights holders in order to protect their video and audio content against unauthorised distribution. There are wide ranges of DRM systems that have been integrated for use in different end user devices (such as tablets, music players, mobile phones, game consoles, and even PCs). These DRM systems are typically implemented in a tamper resistant manner, making it difficult for an attacker to obtain the sensitive information needed to strip the DRM protection or to emulate the DRM client implementation.
Many end user devices (especially mobile smart phones) use Android as an operating system. This open source operating system allows easy modifications by end users, which could potentially lead to significant problems with unauthorised distribution of content. The deployment of embedded hardware DRM implementations enables content distribution to such platforms whilst at the same time protecting against unauthorised distribution. For example, the Galaxy S3 mobile smart phone contains a hardware-assisted and very robust implementation of a DRM client. The implementation details of the DRM client, such as the hardware circuits used, the robustness criteria and the secure storage for keys, are proprietary to the various hardware providers and/or the DRM system providers.
PCT/CN2013/073241 describes a challenge-response method for a client device (i.e. an end user device). In particular, PCT/CN2013/073241 relates to a DRM implementation of a challenge-response node locking function in a client device. The “challenge” is DRM protected content which includes a nonce. A client device is able to use its own DRM system to extract the nonce from the challenge so as to provide the nonce as a response. The challenge data could be any content encrypted using an encryption key, the content including a nonce. However, in a specific implementation described below with reference to FIGS. 1 and 2, the challenge data is DRM protected audio content (e.g. a DRM protected audio file, or streamed DRM protected audio content).
The system 10 of FIG. 1 includes a random number generator 12, an error protection module 14, an audio data insertion module 16 and a secured DRM module 18. The random number generator 12 (which may be a pseudo-random number generator) is operable (or arranged) to generate a nonce. It should be noted that, for some applications, the nonce may contain non-random information. The error protection module 14 is an optional element of the system and is operable to encode the nonce with an error correcting code (ECC) in order to protect against data distortions in the nonce recovery process. In other words, the error protection module 14 is used to add redundancy to the nonce such that the nonce may be recovered by the client device even in cases of incomplete data transmission, for example.
Audio content (e.g. an audio file) and the ECC protected nonce are provided as inputs to the audio data insertion module 16. The audio data insertion module 16 is operable to insert the ECC protected nonce into the audio content. There are a number of ways in which the ECC protected nonce may be embedded into the audio content. The ECC protected nonce may be added as an audio watermark. Alternatively, the ECC protected nonce is included in the content using a modulation encoding technique. For example, the ECC protected nonce may be encoded/embedded using audio frequency-shift keying (AFSK) or similar modulation encoding formats. Embedding the ECC protected nonce as an audio watermark produces a more pleasant audio output than embedding using AFSK or the like, but may need a longer audio fragment to embed the ECC protected nonce. The output of the audio data insertion module 16 is plaintext/cleartext (i.e. non-encrypted) audio content (i.e. a plaintext audio file).
The secured DRM module 18 is operable to generate a DRM protected version of the audio content for a particular client device having a particular “DRM client ID”. In fact, the “DRM client ID” is associated with a secured DRM module of the particular client device. The secured DRM module 18 of FIG. 1 is operable to process the plaintext audio content using the DRM client ID so as to generate a DRM protected version of the audio content that is suitable for playback on the identified client device. The secured DRM module 18 achieves this using encryption based on one or more encryption keys for the identified client device (i.e. keys associated with the secured DRM module of the client device). The encryption keys and encryption algorithms are known to the DRM system only. For example, the encryption keys may be known only to the secured DRM module 18, and the corresponding decryption keys may be known only to the secured DRM module of the particular client device. There are many cryptographic techniques suitable for use in such a DRM system. The DRM protected audio content 20 is output by the secured DRM module 18.
FIG. 2 schematically illustrates a client device 30 (e.g. a mobile phone or a tablet computer) for implementing the challenge-response methodology of PCT/CN2013/073241. The client device 30 includes an input module 32, a secured DRM module 34, an audio decoder 36, a speaker 38, a microphone 40, an audio recorder 42, a processor 44, and an output module 48. Together, these elements of the client device 30 perform the node locking function (schematically shown by the dashed line 52 in FIG. 2).
The DRM protected audio content 20 output by the secured DRM module 18 of FIG. 1 forms the “challenge” (or challenge data). The input module 32 is operable to receive the challenge data 20 and to pass it to the secured DRM module 34 of the client device 30. For example, the input module 32 may send the challenge data with a rendering request to the secured DRM module 34. A secured DRM module API (not shown) may be used to activate the secured DRM module 34.
The secured DRM module 34 is operable to decrypt the challenge data 20 using a decryption key of the secured DRM module 34. Specifically, the secured DRM module parses the DRM encoded usage rules associated with the DRM protected audio content 20, and then decrypts the DRM protected audio content 20 in accordance with these rules. The decrypted audio content is transferred to the audio decoder 36 using a secured data channel.
The audio decoder 36 produces an audible output using the speaker 38 of the client device 30. Thus, the secured DRM module effectively outputs an audible version of the audio content by means of the audio decoder 36 and the speaker 38.
The microphone 40 of the client device 30 is operable to receive the audible version of the audio content output by the speaker 38. The audio recorder 42 is operable to record the sound captured by the microphone 40 so as to provide a recording of the audio content. Such a recording of the audio content will be imperfect such that the recording is a modified version of the original audio content (as output by the audio decoder 36 and the speaker 38). For example, the quality of the speaker 38 and the microphone 40 will affect the recording (particularly in certain frequency bands). The recording will also capture environmental noise. Thus, the audible version of the audio content received by the microphone 40 (and recorded by the audio recorder 42) will generally be slightly different from the audible version of the audio content output by the speaker 38.
The processor 44 is operable to process the recording to obtain the nonce. The processor includes an audio data extraction module 45 and an error correction module 46. The audio data extraction module 45 is operable to access the recording of the audio content made by the audio recorder 42. The audio data extraction module 45 is further operable to recover the ECC protected nonce from the recording using signal processing techniques. In other words, the audio data extraction module 45 is operable to use signal processing techniques to extract the nonce from the version of the audio content received by the microphone 40. The signal processing techniques used by the audio data extraction module 45 will depend on the way in which the nonce has been included in the audio content (e.g. as an audio watermark or using a modulation encoding technique).
Thus, FIG. 2 schematically illustrates the arrangement of PCT/CN2013/073241 in which the decrypted content is obtained by capturing an analogue output (i.e. by recording the playback of an audio file) and processing the captured analogue output of the content to extract an embedded data signal.
Having extracted the ECC protected nonce from the audio content, the audio data extraction module 45 passes the ECC protected nonce to the optional error correction module 46. The error correction module 46 is operable to decode the ECC protected nonce to provide the original nonce. The output module 48 is operable to receive the nonce from the error correction module 46 of the processor 44 and to provide the nonce as an output of the node locking function 52. Hence, the nonce may be considered as the “response”.
Thus, the DRM protected audio content 20 is used in the client device 30 as a challenge input to a node locking function 52 in order to obtain a response 50. The response 50 should be equal to the nonce (see above) and will only be obtainable by the particular client device 30 containing the particular secured DRM module 34 having the relevant decryption keys. The decryption key used may be unique to (i.e. known only to) the particular secured DRM module 34 such that all other client secured DRM modules are unable to decrypt the challenge data 20. In other cases, the decryption key used may be unique to (i.e. known only to) a group of client secured DRM modules such that only secured DRM modules in the group are able to decrypt the challenge data 20 and secured DRM modules not in the group are unable to decrypt the challenge data 20.
In the challenge-response methodology of PCT/CN2013/073241, an application issues DRM protected content that contains the challenge. The protected content can only be rendered on a specific computing platform. The challenge-response methodology of PCT/CN2013/073241 thereby enables a secured application to prevent clones from executing on different computing platforms (e.g. different client devices).